Modern business may rely heavily on databases to keep vital records such as clients, services, suppliers, billing records, and inventory. When database hardware or software fails, it becomes imperative to recover the database so that operations with the database may continue. In very large databases, recovery may be lengthy and costly. Generally, access to the database may be limited during recovery because existing techniques do not provide a method for access during the recovery phase.
FIG. 1 depicts the recovery timeline 100 of a database. The three stages of a recovery are the analysis phase 105 (A to B), the redo phase 110 (B to C), and the undo phase 115 (C to D). The analysis phase 105 generally includes reading and analysis of the log file associated with the database. Often, a log file is generated concurrent with database operations, for example, during a database update operation, the log file records transactions that occur against the database. Those transactions may start a read operation and may end with a write operation. However, a database event, such as a disk crash may occur before the written data is committed into the database. Thus, a log file may contain both committed and uncommitted transactions. The analysis phase 105 of a database recovery typically includes reading all of the transactions on the log file.
The redo phase 110 of the database recovery timeline 100 compares the log file entries with the database. If a transaction in the log file is represented in the database, the next entry in the transaction log file is examined. If the transaction present in the log file is not in the database, the redo phase re-applies the transaction log to the database file to record the transaction as part of the recovery process. However, the re-entered transaction may be incomplete because it was never committed into the database. Transactions that are already in the database and do not need to be re-entered may also be incomplete.
By selectively removing the uncommitted transactions from the database, the database reconstruction may result in a transactionally consistent form after the recovery operation. The undo phase 115 of database recovery rolls back the transaction from the database in those instances where the log file has no record of a commitment of the transaction. Consequently, uncommitted transactions are removed so that the database recovery may result in a consistent set of committed transactions.
Some prior art systems which use the database recovery scheme of FIG. 1 cannot allow access to the database until after the undo phase 115. That is, prior art systems can not allow access to the database until all recovery operations are completed. Prior art systems only allow access after point D in the recovery timeline 100.
Thus, there is a need for an architecture and method that may allow for an earlier entry for accessibility into a database recovery timeline. The present invention addresses the aforementioned needs and solves them with additional advantages as expressed herein.